On a computer that supports the Internet Protocols, two of the more prominent service means to obtain access to services are INETD and Remote Procedure Call (RPC).
INETD
INETD provides an Internet service access system for many computer systems in order to provide access to a variety of services and protocols. These services can include:
TABLE 1: ______________________________________ Sample Internet Services Service Port/Protocol ______________________________________ echo 7/tcp echo 7/udp discard 9/tcp discard 9/udp systat 11/tcp daytime 13/tcp time 37/udp rlp 39/udp nameserver 42/udp ______________________________________
and many others. On a particular computer system used to prepare this document the combined count of Internet and Unix services is 72.
These services are typically available on or from all computers with the Internet protocols. The assignment of Internet service port numbers is centrally administrated by the Internet Assigned Numbers Authority (IANA) (the assignments are made in the Assigned Number RFC, the most recent being RFC1700), and the number of available ports, 65536 (64K) is small in proportion to both the number of computers using the Internet protocols, and to the number of potential applications that could use or provide Internet protocol access.
RPC Service
Many computers use a Sun Microsystems NFS file system service. A Remote Procedure Call (RPC) service is required to implement the NFS service. The RPC service provides a standardized method for client programs to address service requests to server programs or procedures on local and remote machines. These service procedures may include:
TABLE 2 ______________________________________ Sample Sun Remote Procedure Call Service Program Version Protocol Port Alias ______________________________________ 100000 2 udp 111 portmapper 100004 1 666 ypserv 100028 1 671 ypundated 100005 2 720 mountd 100020 1 795 llockmgr ______________________________________
and many more. There were 75 RPC services available on the computer that provided this sample.
Some of the RPC services are available on computers equipped with the Sun NFS service. Others are provided as a part of some software vendors products.
Sun Microsystems defines the administration of RPC program numbers. The numbers are assigned in eight groups of 0x2000 0000 (about 540 million). The first group is defined by Sun Microsystems; the second group is defined by the user (usually a software developer), and the third group is defined by applications that dynamically generate program numbers. The rest of the groups are apparently reserved for future use.
Limitations of the Prior Art
Both INETD and RPC services are oriented towards generic or general services and consequently have a wide range of applicability, e.g. ftp, ypbind, but they do not directly support the provision of multiple instances of services. In the case of situations involving the accessing of a large number of small specialized services, with multiple instances of those services the prior art services are less than suitable.
The services accessible by INETD are started when needed and die when the client application is finished with the services. The INETD service cannot connect a client to a service that is already running.
The RPC service always operates in a client/server mode, and the TCP/IP protocol requires a client/server relationship when communications is established.
A client/server relationship paradigm between computer applications that have peer to peer communications requirements, introduces an intermediary application that is unsatisfactory, due to increased system complexity. Also, when a client/server relationship is to be used between applications an implied order of application startup is created. This is not acceptable for a system with 7.times.24 (i.e. seven day 24 hours per day) availability requirements. If a server application near the top of the client/server hierarchy must be restarted, all subordinate applications in the hierarchy would have to be restarted or notified to reestablish their connections to nodes above them. Also, the server application would have no way to send unsolicited status messages to the client; the client would have to poll the server for status. For the use of a particular connection services as the application "node" (collection of applications) access server in a broadband video conferencing system with a distributed control architecture, the above-mentioned limitations are not acceptable.